微服务架构设计模式
Microservices Patterns
李杉杉
02
微服务核心设计模式
• 挑战问题
• 模式和模式语言
• 模式集合及示例
• 补充模式
微服务架构可观测性模式
微服务架构部署模式
微服务架构可观测性模式
微服务架构部署模式
部署的流程和架构发展变化
• 20世纪90代(企业级Java应用）
• 微型机时代
• 开发团队向运维团队提交部署工单（手动部署）
• 昂贵且重量级的应用服务器，如WebLogic
• 定期安装补丁并更新软件
• 21世纪最初10年
• 开源的轻量级Web容器，如 Tomcat
• 虚拟机开始取代物理机，仍手动部署
• 2010年后-至今
• 高度自动化云上虚拟机
• 更轻量级、一次性资源、用过即丢弃/重建
• 容器、serverless等
• DevOps实践和自动化基础设施对微服务的支持
……
部署 可观测性
……
部署 可观测性
• 上下文
• 微服务架构包含一组服务
• 每个服务都部署为一组服务实例，以实现吞吐量和可用性
• 问题：如何部署？
• 需求：
• 服务使用各种语言、框架和框架版本编写
• 需要快速构建、独立部署和扩展服务
• 服务实例需要相互隔离
• 需要监控每个服务实例的行为、部署可靠
• 需要限制服务消耗的资源（CPU 和内存）
• 尽可能经济高效地部署应用程序
• 部署模式列表
● 单主机部署多个服务实例
● 单主机部署多个服务实例
● 将服务部署到虚拟机
● 将服务部署到容器
● 服务部署平台
● 无服务器部署
基础设施相关模式组-部署模式
……
部署 可观测性
• 模式：单主机部署多个服务实例
• 资源需求冲突的风险
• 在主机（物理机或虚拟机）上运行不同服务的多个实例。
• 有多种方法可以在共享主机上部署服务实例，包括：
• 将每个服务实例部署为一个 JVM 进程。例如，每
个服务实例一个 Tomcat 或 Jetty 实例。
• 在同一个 JVM 中部署多个服务实例。例如，作为
Web 应用程序或 OSGI 包。
• 优点：资源利用率相对较高
• 缺点：
• 资源需求冲突的风险
• 依赖版本冲突的风险
• 难以限制服务实例消耗的资源
• 在同一个进程中部署多个服务实例，很难监控每个服务
实例的资源消耗，也不可能隔离每个实例
• 相关模式：
• 替代模式：单主机部署单个服务实例
……
部署 可观测性
• 模式：单主机部署单个服务实例
• 在自己的主机上部署单个服务实例
• 优点：
• 服务实例彼此隔离
• 不存在资源需求或依赖版本冲突的可能性
• 一个服务实例最多只能消耗单个主机的资源
• 监控、管理和重新部署每个服务实例非常简单
• 缺点：
• 与单主机部署多个服务实例模式相比，资源利用效率可
能较低，因为主机更多
• 相关模式：
• 替代模式：单主机部署多个服务实例、无服务器部署
• 特化模式：将服务部署到虚拟机、将服务部署到容器
Host
……
部署 可观测性
• 模式：将服务部署到虚拟机
• 将服务打包为虚拟机镜像，并将每个
服务实例部署为单独的VM
• 比如Netflix部署流水线将每个服务
打包为一个 EC2 AMI（包含服务运
行所需要的所有内容）
• 运行时每个服务实例是该镜像实例化
的虚拟机，如EC2 实例
• EC2弹性负栽均衡器(Elastic Load
Balancer)将请求路由到对应的实例
……
部署 可观测性
• 优点：
• 通过增加实例数量来扩展服务很简单。 Amazon Autoscaling
Groups 可以根据负载自动执行此操作
• VM 封装了用于构建服务的技术细节，例如所有服务都以完全相
同的方式启动和停止
• 每个服务实例都是隔离的
• VM 对服务实例消耗的 CPU 和内存施加限制
• AWS 等 IaaS 解决方案为部署和管理虚拟机提供了成熟且功能
丰富的基础设施，如弹性负载均衡器、自动缩放组
• 缺点：
• 资源利用效率较低（整台虚拟机）
• 部署速度相对较慢（分钟级）
• 系统管理的额外开销（操作系统、运行补丁）
• 相关模式：
• 替代模式：将服务部署到容器
• 泛化模式：单主机部署单个服务实例
……
部署 可观测性
• 模式：将服务部署到容器
• 将服务打包为 (Docker) 容器镜像并将每个服务实
例部署到容器
• 容器是一种更现代、更轻量级的部署机制，操作系统
级的虚拟化机制
• 容器由在隔离的沙箱中运行的一个或多个进程组成，
多个容器通常在一台机器上运行，容器共享操作系统
• 从在容器中运行的进程的角度来看，它就好像在自己
的机器上运行一样，有独立IP、可消除端口冲突
• 使用Docker 编排框架指定并协调容器资源， 如
Kubernetes、 Marathon/Mesos、 Amazon EC2
Container Service
• 部署过程：
• 构建Docker镜像：在构建时， 部署流水线使用容器
镜像构建工具，该工具读取服务代码和镜像描述，以
创建容器镜像并将其存储在镜像仓库中。
• 运行Docker镜像：在运行时， 从镜像仓库中拉取容
器镜像，并用于创建容器。
……
部署 可观测性
• 模式：将服务部署到容器
• 构建Docker镜像
• 创建Dockerfile：指定基础容器镜像、一系列用
于安装软件和配置容器的指令，以及在创建容器
时运行的脚本命令（Listing 12.1）
• 为Restaurant Service构建镜像的Dockerfile
• 构建一个包含服务的可执行JAR文件的容器镜像
• 基础镜像openjdk:8ul71-jre-alpine
• 安装curl用于健康检查
• 容器配置：在启动时运行java-jar命令
• 容器配置：定期调用健康检查端点（30s，5s）
• 将服务的JAR从Gradle构建目录复制到镜像中
• 构建容器镜像： docker build命名
• -t指定镜像的名称
• .指定Docker调用上下文的内容（当前目录）
• 将上下文上传到Docker守护进程，构建镜像
• 推送到镜像仓库： docker push命名
• Docker Hub：公共Docker镜像仓库的示例
• 私有镜像仓库， 如 Docker Cloud 镜像仓库或
AWS EC2 Container Registr y
• 运行Docker镜像：docker run命令
……
部署 可观测性
• 优点：
• 通过更改容器实例的数量可以直接扩展和缩减服务
• 容器封装了用于构建服务的技术细节，所有服务都以完全相同的
方式启动和停止
• 每个服务实例都是隔离的
• 容器对服务实例消耗的 CPU 和内存施加限制
• 容器的构建和启动速度非常快
• 将应用程序打包为 Docker 容器比将其打包为 AMI 快 100 倍
• Docker 容器启动速度明显快于 VM （仅启动应用程序进程而非整
个操作系统）
• 缺点：
• 大量的容器镜像管理工作（操作系统补丁、基础设施）
• 部署容器的基础设施不如部署虚拟机的基础设施丰富
• 相关模式：
• 替代模式：将服务部署到虚拟机
• 泛化模式：单主机部署单个服务实例
……
部署 可观测性
• 模式：无服务器部署
• 使用公有云提供的serverless部署机制部署服务
• 部署细节对用户隐藏，用户和其组织不负责管理低级基础设施(无服务器概念）
• 基础设施获取服务代码并运行，根据消耗的资源为每个请求付费
• 需打包代码（例如 ZIP ），将其上传到部署基础设施
• 公有云serverless平台：AWS Lambda、Google Cloud Functions、Azure Functions
• 开源serverless框架：Apache Openwhisk、Fission on Kubernetes
ü AWS Lambda支持Java、Node.js、C#、GoLang和Python
ü AWS Lambda函数是无状态服务
……
部署 可观测性
• 模式：无服务器部署 - AWS Lambda
• 将服务的代码打包到一个 ZIP 文件中，
将其上传到 AWS Lambda
• restaurant－service-aws-lambda.zip
• 实现Restaurant Service服务功能
• 每一个Lamba函数都有一个请求处理类
• ftgo-create-restaurant Lambda函数
• CreateRestaurantRequestHandler类
• 当事件发生时，AWS Lambda 寻找函
数的空闲实例，没有可用实例则新启动
并调用处理程序函数
• AWS Lambda 运行足够的函数实例来
处理负载， 使用容器来隔离 lambda
函数的每个实例（EC2 上运行）
使用AWS Lambda部署Restaurant Service
……
部署 可观测性
• 优点：
• AWS服务集成简单：AWS服务生成事件、AWS API Gateway处理HTTP请求的Lambda函数
• 消除系统管理任务：底层系统管理、操作系统或运行时打补丁，专注于开发应用程序
• 弹性伸缩：AWS Lambda运行应用程序所需的多个实例以动态处理负载
• 基于使用情况的定价：与典型的laaS云不同，AWS Lambda按请求所消耗的资源收费
• 缺点：
• 长尾延迟：AWS Lambda动态运行代码， 需花费时间配置和启动应用，某些请求具有高延迟
（Java服务通常需要至少几秒钟，不适合对延迟敏感的服务）
• 基于有限事件与请求的编程模型：不用于长时间运行的服务（使用第三方消息代理的消息服务）
• 相关模式：
• 替代模式：
• 单主机部署单个服务实例
……
部署 可观测性
• 模式：服务部署平台
• 使用部署平台作为应用程序部署的自动化基础设施
• 提供服务抽象（一组命名的、高度可用的服务实例）
• Docker 编排框架，包括Docker swarm 模式和
Kubernetes
• 无服务器平台，例如 AWS Lambd a
• PaaS，包括Cloud Foundry和AWS E lastic
Beanstalk
• Docker编排框架将运行Docker的一组计算机转变为资源集
群，将容器分配给机器，提供资源管理、调度、服务管理功能
• 相关模式：
• 后续模式：
• 将服务部署到虚拟机
• 将服务部署容器
• 无服务器部署
……
部署 可观测性
• 模式：服务部署平台 - Kubernetes集群
• Google于2014年开源，简称K8s
• 由管理集群的主节点和运行服务的普通节点组成
• 通过API服务器与Kubernetes交互，API服务器与主节点
上运行的其他集群管理软件一起运行
• 应用程序容器在节点上运行，每个节点运行多个组件
• Pod s：应用程度服务容器
• Kubelet：创建和管理节点上的应用程序容器（Pod）
• Kube-proxy ：管理网络， 将应用程序请求路由到
Pod， 包括跨Pod的负载均衡。可以直接使用代理，
也可以通过配置Linux内核中内置的iptables路由规
则间接地完成路由工作
……
部署 可观测性
• 小结：应选择支持服务要求的最轻量级部署模式：Serverless、容器、虚拟机……
模式
优点
缺点
无服务器
• 消除管理操作系统和运行时状
态的必要性
•
自动弹性配置
•
基于请求的定价
•
长尾延迟
•
使用基于事件／请求的编程模型
容器
•
必须管理操作系统和运行时
•
需要管理 Docker编排框架及
其底层运行的虚拟机
•
轻量级，比Serverless部署更灵活
•
延迟可预测
虚拟机
•
Amazon EC2等现代云
• 部署小型简单应用程序可能比
设置Docker编排框架更容易
•
重量级且部署速度较慢
•
使用更多的资源
服务部署平台
•
多种后续模式支持
•
功能强大
•
额外的技术学习和资源成本
主机（单
/多）
——
——
……
部署 可观测性
微服务架构可观测性模式
微服务架构部署模式
• 上下文
• 多台机器上、多个服务和服务实例
• 请求跨越多服务实例，每个服务通过执行一
个或多个操作来处 理请求
• 以标准化格式将操作信息写入日志文件，跟
踪用户行为和代码异常
• 服务实例可能无法处理请求但仍在运行
• 问题：
• 如何理解用户和应用程序的行为并解决问题？
• 如何检测正在运行的服务实例无法处理请求？
• 模式列表：
• 日志聚合
• 审计日志
• 应用程序指标
• 分布式跟踪
• 异常跟踪
• 健康检查API
……
部署 可观测性
日志聚合模式
• 问题：如何理解应用程序的行为并解决问题？
• 需求：任何解决方案都应该具有最小的运行时开销
• 模式：日志聚合模式
• 使用集中式日志记录服务聚合来自每个服务实例的日志
• 用户可搜索和分析日志
• 可配置当某些消息出现在日志中时触发的警报
• 实例： AWS Clou d Watch , Logstash ( ELK )
• 缺点：
• 处理大量日志需要大量的基础设施
• 相关模式：
• 分布式追踪、异常跟踪
……
部署 可观测性
日志记录的基础设施：
● ELK
• Elasticsearch：面向文本搜索的NoSQL数据库，
用作日志记录服务器
• Logstash：聚合服务日志并将其写入
Elasticsearch的日志流水线
• Kibana: Elasticsearch的可视化工具
● 开源日志流水线包括Fluentd和Apache Flume
● 商用如AWS Cloud Watch Logs等
……
部署 可观测性
审计日志模式
• 问题：如何理解用户和应用程序的行为并检
测定位问题？
• 需求：了解用户最近执行了哪些操作，帮助
支持、确保合规性、安全性和可疑行为等
• 模式：审计日志模式
• 向业务逻辑中添加审计日志代码
• 创建审核日志条目并保存在数据库中
• 优点:
• 提供用户操作的记录
• 缺点：
• 审计代码与业务逻辑交织，使业务逻辑复杂化
• 相关模式：
• 后续模式：事件溯源（实施审计的可靠方式）
……
部署 可观测性
应用程序指标模式
• 问题：如何理解应用程序的行为并检测定位问题？
• 需求：任何解决方案都应该具有最小的运行时开销
• 模式：应用程序指标模式
• 检测服务以收集有关各个操作的统计信息，在集中式指标
服务中聚合指标，提供报告和警报。聚合指标两种模型：
• push - 服务将指标推送到指标服务
• pull - 指标服务从服务中提取指标
• 实例：Coda Hale/Yammer Java 指标库、
Prometheus（普罗米修斯）、AWS Clou d Watch 等
• 优点:
• 提供对应用程序行为的深入洞察
• 缺点：
• 指标代码与业务逻辑交织在一起，使其更加复杂
• 聚合指标可能需要大量的基础设施
• 相关模式：
• 其他可观测性模式
……
部署 可观测性
分布式追踪模式
• 问题：如何理解应用程序的行为并解决问题？
• 需求：
• 外部监控只报告总体响应时间和调用次数，无法深入
了解各个操作
• 任何解决方案都应该具有最小的运行时开销
• 请求的日志条目分散在许多日志中
• 模式：分布式追踪模式
• 记录单次请求范围以内的信息
• 为每个外部请求分配一个唯一的外部请求 ID
• 并在提供可视化和分析的集中式服务器中记录请求如
何从一个服务流向下一个服务
• 在所有日志消息中包含外部请求 ID
• 记录在集中服务中处理外部请求时执行的请求和操作
的信息（例如开始时间、结束时间）
……
部署 可观测性
• 模式：分布式追踪模式
• Spring Cloud Sleuth - Spring Cloud 应用程
序的分布式跟踪
• Open Zipkin - 用于记录和显示跟踪信息的服务
• Open Tracing - 用于分布式跟踪的标准化 API
• 优点:
• 提供了对系统行为的有用洞察，包括延迟的来源
• 使开发人员能够通过在聚合日志中搜索其外部请
求 ID来查看单个请求是如何处理的
• 缺点：
• 聚合和存储追踪数据可能需要大量的基础设施
• 相关模式：
• 日志聚合- 外部请求 ID 包含在每个日志消息中
分布式追踪模式
……
部署 可观测性
异常追踪模式
• 上下文：处理请求时有时会发生错误。发生错误时，
服务实例会抛出异常，其中包含错误消息和堆栈跟踪
• 问题：如何理解应用程序的行为并解决问题？
• 需求：
• 异常必须由开发人员去重、记录、调查并解决潜在问题
• 任何解决方案都应该具有最小的运行时开销
• 模式：异常跟踪模式
• 向集中式异常跟踪服务报告所有异常，该服务聚合和跟
踪异常并通知开发人员。
• 实例：Sentry Datadog、PagerDu ty
• 优点：
• 更容易查看异常并跟踪其解决方案
• 缺点：
• 异常跟踪服务是额外的基础设施
• 相关模式：
• 日志聚合-应记录异常并报告给跟踪服务
……
部署 可观测性
• 模式：健康检查API模式
• 使用 Spring Boot 和 Spring Cloud 作为微服务框架
• 提供健康检查端点，由Spring Boot Actuator模块实现
• 配置调用/health可扩展健康检查逻辑的 HTTP 端点。
• 优点：
• 定期测试服务实例的健康状况
• 缺点：
• 不够全面
• 服务实例可能在健康检查之间失败
• 相关模式：
• 前置模式：服务注册与发现模式、部署相关模式
……
部署 可观测性
小结：
• 开发人员和运维人员共同负责实现可观测性模式
• 运维人员负责可观测性基础设施
• 处理日志聚合、应用指标、异常追踪和分布式追踪的服务器
• 开发人员有责任确保服务是可观测的
• 健康检查API端点
• 生成日志条目
• 收集和公布指标
• 向异常追踪服务报告异常
• 实现分布式追踪
……
部署 可观测性
……
部署 可观测性
……
部署 可观测性
作业（3-4人小组为单位）：
1. 选取一个开源的微服务系统
• GitHub上检索
• Star数量超过500
• 若第二次作业已经有微服务系统实现可直接使用（需上传到GitHub）
2. 选择合适的部署和可观测性相关模式，进行实践
• 提供模式决策理由
• 给出详细的实践文档（含效果截图）
谢谢观看
